Clarify HTTP/2 setting parameter reservation #3955
Conversation
MikeBishop
added
design
draft-ietf-quic-http.md
Outdated
| @@ -1395,6 +1395,10 @@ settings to have any meaning upon receipt. | |||
| Because the setting has no defined meaning, the value of the setting can be any | |||
| value the implementation selects. | |||
|
|
|||
| Setting identifiers which were used in HTTP/2 where there is no corresponding | |||
| HTTP/3 setting have also been reserved ({{iana-settings}}). These settings MUST | |||
| NOT be sent, and receipt MAY be treated as an error of type H3_SETTINGS_ERROR. | |||
There was a problem hiding this comment.
The MAY here could lead to confusion down the road. Is there any reason for us to not be prescriptive here? I think it would be safer to clearly have either MUST treat as error or MUST ignore here.
There was a problem hiding this comment.
We've used MUST NOT send / MAY error elsewhere when we haven't wanted to mandate checking. It's enough of a deterrent to the bad behavior, when the requirement to treat as an error isn't vital to interop. That said, it also isn't difficult to do the check, so if there's consensus to require it, I'm not opposed to the suggestion.
There was a problem hiding this comment.
I would be in favor of MUST treat as error. This isn't hard to detect, and it seems quite reasonable to close the connection on such errors.
draft-ietf-quic-http.md
Outdated
| @@ -2316,20 +2320,26 @@ SETTINGS_HEADER_TABLE_SIZE: | |||
|
|
|||
| SETTINGS_ENABLE_PUSH: | |||
| : This is removed in favor of the MAX_PUSH_ID which provides a more granular | |||
| control over server push. | |||
| control over server push. Specifying a setting with the identifier 0x2 | |||
There was a problem hiding this comment.
Could we instead phrase these as normative? For example: Endpoints MUST NOT send a setting with identifier 0x2 (corresponding to the SETTINGS_ENABLE_PUSH parameter) in the HTTP/3 SETTINGS frame.
There was a problem hiding this comment.
Nothing in this appendix is normative, by design. The normative requirement is in the body of the document, and this appendix simply notes that there is a prohibition. I could add a reference to the prohibition, if that would help.
There was a problem hiding this comment.
A reference to the prohibition works for me, I just want to make sure we have easily-discoverable text clearly stating that endpoints MUST NOT send those
draft-ietf-quic-http.md
Outdated
| @@ -1395,6 +1395,10 @@ settings to have any meaning upon receipt. | |||
| Because the setting has no defined meaning, the value of the setting can be any | |||
| value the implementation selects. | |||
|
|
|||
| Setting identifiers which were used in HTTP/2 where there is no corresponding | |||
| HTTP/3 setting have also been reserved ({{iana-settings}}). These settings MUST | |||
| NOT be sent, and receipt MAY be treated as an error of type H3_SETTINGS_ERROR. | |||
There was a problem hiding this comment.
| NOT be sent, and receipt MAY be treated as an error of type H3_SETTINGS_ERROR. | |
| NOT be sent, and their receipt MAY be treated as an error of type H3_SETTINGS_ERROR. |
draft-ietf-quic-http.md
Outdated
| @@ -1395,6 +1395,10 @@ settings to have any meaning upon receipt. | |||
| Because the setting has no defined meaning, the value of the setting can be any | |||
| value the implementation selects. | |||
|
|
|||
| Setting identifiers which were used in HTTP/2 where there is no corresponding | |||
| HTTP/3 setting have also been reserved ({{iana-settings}}). These settings MUST | |||
| NOT be sent, and receipt MAY be treated as an error of type H3_SETTINGS_ERROR. | |||
There was a problem hiding this comment.
I would be in favor of MUST treat as error. This isn't hard to detect, and it seems quite reasonable to close the connection on such errors.
|
@LPardue points out that SETTINGS and frames are different, because of tunneling intermediaries. The intermediary need not check every received frame for validity if they're not processing the frames. SETTINGS, on the other hand, have to be checked because they're inherently hop-by-hop. While I'm not crazy about having SETTINGS and frames be different, there is at least a justification for it. |
MikeBishop
added
the
proposal-ready
|
I'm sorry @MikeBishop, that makes no sense. You can't pick and choose which parts of a protocol you understand. |
|
@MikeBishop : Doesn't that argument then argue for MUST close the connection on error? What am I missing? |
martinthomson
removed
the
proposal-ready
|
@martinthomson, that goes back to the discussion we had around stream vs. connection errors. @kazuho's point, if I can summarize briefly, is that an intermediary might directly copy some things from its connection to the client onto its connection to the server, or vice versa. That led to the logic of using connection errors for things definitely generated by your peer; settings are definitely generated by the peer, which argues for "MUST error," while frames might have come from upstream. However, I note that we currently don't specify whether receiving a reserved frame type is a stream or a connection error, so I've opened #3991 for that. |
|
I'm going to argue that frames also need to definitely come from a peer. If SETTINGS definitely comes from an immediate peer, then transport-level intermediation is not valid. That is, you forward (HTTP) frames blindly at your own risk. That is, if you indicate in SETTINGS that you understand an extension and then blindly forward frames related to that extension, you are responsible for the effects. |
Fixes #3954 by copying the language we already had for frame types and taking @martinthomson's suggestion from #3942.